Digital Asset Custodial System

ABSTRACT

A digital asset custodial system for maintaining custody of, and controlling access to, cryptocurrencies and/or other digital assets, is disclosed. The digital asset custodial system includes multiple layers of security to enable large volumes of digital assets to be maintained in a secure manner. The digital asset custodial system can include a combination of biometric-based multi-user validation, transaction risk analysis, and a hardware security module (HSM) that provides authentication/validation functionality and secure storage of private keys of digital assets.

This application claims the benefit of U.S. provisional patentapplication No. 62/636,106 filed on Feb. 27, 2018, and U.S. provisionalpatent application No. 62/640,429 filed on Mar. 8, 2018, each of whichis incorporated by reference herein in its entirety.

FIELD

At least one embodiment of the present disclosure pertains to computersystems, and more particularly, to a computer-implemented system formaintaining custody of digital assets, such as cryptocurrencies.

BACKGROUND

Cryptocurrencies such as Bitcoin, Ethereum, Ripple and others havegained in popularity and value in recent years and are expected by manyto continue to do so. Every day an increasing variety of transactionsare conducted based on cryptocurrencies, and it is conceivable that newtypes of cryptographic assets may be created in the future, i.e.,cryptographic assets that are not necessarily currencies.

With the increasing use of cryptoassets comes the need for a trustedcustodial system that can securely store very large quantities ofcryptoassets and control access to those cryptoassets. Indeed, U.S.securities regulations require certain entities that hold more than acertain amount of funds (e.g., $150 million) on behalf of another partyto use a custodian to hold those funds. Hardware wallets and other formsof “cold storage” are sometimes used to store cryptocurrency, however,those devices limit access only to the owner of the device and aretherefore not suitable for many business uses, where a number ofindividuals may require access to cryptographic funds or othercryptoassets.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present disclosure are illustrated by wayof example and not limitation in the figures of the accompanyingdrawings, in which like references indicate similar elements.

FIG. 1 is a high-level block diagram of a cryptoasset custodial system(CCS).

FIG. 2A is a schematic diagram illustrating an example of a depositprocess flow with the CCS.

FIG. 2B is a flow diagram illustrating an example of the deposit processflow.

FIG. 3A is a schematic diagram illustrating an example of a withdrawalprocess flow with the CCS.

FIG. 3B is a flow diagram illustrating an example of the withdrawalprocess flow.

FIG. 4 is a flow diagram illustrating an example of a process performedby the hardware security module (HSM) in connection with a requestedoperation.

FIG. 5 is a flow diagram illustrating an example of a process for usingan offline user device to endorse a requested transaction.

FIG. 6 is a high-level block diagram showing an example of a hardwarearchitecture of a processing system that can be used to implement someor all of the CCS or a user device.

DETAILED DESCRIPTION

In this description, references to “an embodiment”, “one embodiment” orthe like, mean that the particular feature, function, structure orcharacteristic being described is included in at least one embodiment ofthe technique introduced here. Occurrences of such phrases in thisspecification do not necessarily all refer to the same embodiment. Onthe other hand, the embodiments referred to also are not necessarilymutually exclusive.

Overview

Introduced here is a computer-implemented cryptoasset custodial system(CCS), i.e., a computer-implemented system for maintaining custody of,and controlling access to, cryptocurrencies and/or other cryptoassets.The CCS may be owned and/or operated by a business enterprise, referredto herein as the Cryptoasset Custodian. The CCS includes multiple layersof security so as to enable large volumes of cryptoassets to bemaintained in a secure manner. In certain embodiments the CCS includes acombination of biometric-based multi-user validation, transaction riskanalysis, and use of a hardware security module (HSM) to provideauthentication/validation functionality and secure storage of privatekeys of cryptoassets. Furthermore, two or more different biometricauthentication techniques may be applied to any given transactionrequest. As used herein, the term “hardware security module” or “HSM”refers to a special-purpose physical computing device that safeguardsand manages digital keys for authentication and providescryptoprocessing functionality. The HSM can be embodied as a plug-incard or an external device that attaches directly to a computer.

In certain embodiments, when a user requests a transaction involving acryptoasset, such as a withdrawal of transfer of cryptocurrency funds,the CCS causes an endorsement request message to be sent to each ofmultiple user devices, each of which is associated with a different userwho has been defined as potential member of a quorum for transactionsinvolving that cryptoasset (in other embodiments, multiple users mayshare the same user device). The endorsement request message isconfigured to cause each receiving user device to prompt its user toprovide an endorsement of the requested transaction. An endorsement inthis context is an approval or rejection of an operation by a user. Whena user receiving such a prompt endorses the transaction on his or heruser device (e.g., a smartphone, tablet or notebook computer), the userdevice signs an endorsement message with a private key of that user andtransmits the signed endorsement message to the CCS. The private key isstored within a secure enclave within the user device. A secure enclavein each user device is used to store the corresponding user's privatekey and to generate digital signatures of that user.

The HSM determines whether a policy-based quorum of multiple users hasendorsed (approved) a requested action, such as a withdrawal or transferof cryptocurrency funds. It does this by validating the signature by apublic key of a public-private key pair for each of the plurality ofusers, in endorsement messages received from the users. Only afterdetermining that the policy-based quorum of the multiple users hasvalidly endorsed the requested action, the HSM then allows itself toaccess the private key of that particular cryptographic asset (e.g., fora specific deposit of cryptocurrency funds), which the HSM previouslygenerated, and uses that private key to sign the transaction asauthorization that the transaction may proceed. The private key for thatcryptoasset is stored only in the HSM, which does not permit the key tobe read by any entity outside the HSM. Approval of the transaction mayinclude, for example, transmitting the transaction onto a knownblockchain network. In certain embodiments, approval of the transactionby the HSM occurs only if and after the requested transaction has passeda risk review, which may be partially or fully automated. Other detailswill become apparent from the description that follows. Note also thatit is contemplated the system and techniques introduced here can be usedfor secure custody of other types of digital assets besidescryptoassets.

Refer now to FIG. 1, which shows a high-level block diagram of the CCS.In the illustrated embodiment, the CCS 1 includes an online server 2, arelay server 3, a risk analysis stage 4, the HSM 5, and a data storagefacility 6. The data storage facility 6 may include one or moredatabases, which can be or include relational databases or any othertype of mechanism for storing data in an organized way, where the datamay be structured data and/or unstructured data. The HSM 5 also includesits own internal secure storage facility 7. Note that there can bemultiple instances of each of the above-mentioned components in the CCS1, even though only one of each is shown to simplify description. One ormore user devices 8, also called clients, can communicate with the CCS 1via a public computer network 9, such as the Internet. Each of the userdevices may be any one of, for example, a smartphone, tablet computer,laptop computer, desktop computer, or the like. Each user device 8 mayinclude a secure enclave 14, such as an iOS-based secure enclave, whichis used to store the corresponding user's private key and to generatedigital signatures of that user. In at least some embodiments, each userdevice 8 is associated with a different user, and this descriptionhenceforth assumes such an embodiment to facilitate description. Note,however, that it is possible to have embodiments in which multiple usersshare the same user device 8.

The relay server 3 functions as a virtual air gap to isolate the HSM 5from the public computer network 9. The relay server 4 and HSM 5 operatewithin a secure zone 10. The HSM 5 may physically reside in a physicallysecured datacenter with no direct access to any outside network.Messages between the HSM 5 and the online server 2 are routed on ahalf-duplex (outbound request-responses only) connection to the relayserver 3 in the secure zone 10. The relay server 3 disconnects itselffrom the secure network while communicating with the online server 1,and disconnects itself from all external networks while communicatingwith the HSM 5, such that no interactive sessions with those devices canbe established from the outside. This provides virtual “air gap”security to critical infrastructure.

In certain embodiments, the CCS 1 also has access to at least oneblockchain network 11 corresponding to a cryptoassets of which the CCS 1has custody. Access to the blockchain network 11 may be via the publiccomputer network 9, e.g., the Internet.

In some embodiments, each transaction submitted by a customer of the CCS1 will go through the risk analysis stage 4, which may be partially orfully automated. For example, with some embodiments of the CCS 1, ahuman risk analysis agent may evaluate the output of automated riskanalysis software displayed on a risk review dashboard, to make adecision on whether a transaction has been sufficiently authorized to beaccepted. The risk analysis agent or the software can follow a policyset on each individual vault and can look at any of various risk signals(e.g., the amount being transacted, how many users have authorized thistransaction, the location(s) from which the transaction was requestedand approved, the destination address) to compute a final risk scorethat might lead to the transaction being approved or more informationbeing requested.

Deposits

Refer now to FIGS. 2A and 2B, which illustrate an example of the processof depositing a cryptoasset, such as an amount of cryptocurrencies, withthe CCS 1. Deposits are initiated by a customer via the Internet througha software application (hereinafter “the CCS application”)(not shown)executing on a user device 8 of the customer. This can be done by thecustomer's selecting an asset type and requesting a deposit for a givenamount in the CCS application. Once initiated, the request for ablockchain deposit address is then sent to the online server 2, whichreceives the request (step 201) and forwards it (step 202) via the relayserver 3 to the HSM 5 (which as noted above is isolated from theInternet by the relay server 3). The HSM 5 then generates (step 203) anew public-private key pair 21 to correspond uniquely with the deposit,i.e., to correspond with the requested blockchain address. In certainembodiments, the HSM 5 uses the private key of the relevant Organizationand a key derivation function (KDF) to generate the new key pair for theblockchain address. An “Organization” in this context is a datastructure that corresponds to a particular customer, as discussedfurther below. The private key of the newly generated key pair cannot beextracted from the HSM 5, but can be backed up securely in an encryptedfile. Key generation inside the HSM 5 ensures that the private keys 21only exist within the HSM 5, are not available anywhere else in theworld and cannot be accessed by any entity that is external to the HSM5.

The HSM 5 next generates (step 204) the blockchain address for thedeposit from the public key of the newly-created key pair. This can bedone by using a well-known blockchain-specific transformation of thepublic key of the blockchain address. The HSM 5 then signs (step 205)the blockchain address with the Organization's private key and returnsthe signed blockchain address to the online server 2. The online server2 then causes (step 206) the signed blockchain address 22 to be sent tothe customer's user device 8, to cause the user device 8 to present theaddress to the customer in the CCS application on a user device, in aneasy-to-consume format (e.g., as a QR code), for use as a destinationaddress in a blockchain transaction. The CCS application on the userdevice verifies (step 207) the signature of the address beforepresenting the address to customer.

The customer's user device 8 uses the public key of the Organization(which it previously received from the CCS 1 and locally stored) toverify the authenticity of the blockchain address it receives from theCCS 1. The customer then initiates (step 208) a transaction to depositassets into the CCS 1. The transaction might be initiated from anexchange, from the customer's personal wallet, or from anothercryptoasset store. No confirmation is required for the assets to show upin the CCS 1.

The address of the deposit is stored in a collection with otheraddresses belonging to the customer in the CCS 1, known as thecustomer's “vault.” A vault in this context is a data entity thatcontains assets and a policy map containing one or more policiesgoverning deposits and withdrawals from those assets. A cryptoasset isrepresented as a slot inside a vault that can hold an amount of an assettype (e.g., Bitcoin, Ethereum). Once under custody and stored with theCCS 1, an asset is completely under the control of the CCS 1.

The online server 2 determines whether the customer has confirmed thetransaction within the defined time period (steps 209, 210). Once thedeposit transaction is confirmed by customer and confirmed on theblockchain, the customer is so notified (step 211) by the online server2, and the assets are considered to be under custody of the CCS 1. Inthe event confirmation is not received within the defined time period,the online server notifies (step 212) the customer of an error in thetransaction.

Withdrawals

FIGS. 3A and 3B illustrate an example of the process of withdrawing anamount of a previously deposited cryptoasset, such as cryptocurrency.Withdrawals can be initiated from the CCS application on a user device8A by selecting a specific cryptoasset to withdraw and an amount. Onceinitiated, all authorizing parties are made aware of the withdrawalrequest and are required to authorize it individually on their mobiledevices 8A and 8B.

During this process users are required to review the transaction andapprove it, where each user's approval is subject to biometricauthentication (e.g., fingerprint, facial recognition and/or voicerecognition). In certain embodiments, before a withdrawal cansuccessfully move on to the next phase, every request is sent to therisk analysis stage to be inspected for suspicious activity andauthorized as legitimate. The HSM 5 validates that a defined quorum(e.g., a majority) of users authorized the transaction, and that thetransaction was approved by the risk review stage 4. For example, for agiven corporate customer that has five distinct employees who requirethe ability to transfer funds, a suitable quorum configuration might beto have a group of three of those five employees be necessary to moveany funds. The HSM 1 then proceeds with the signature and submission ofthe asset-moving transaction to the blockchain 11.

An example of the withdrawal process is further illustrated in FIG. 3B.The online server 2 initially receives (step 301) the withdrawal request31 from the customer. The online server 2 then checks (step 305) theapproval policy for the cryptoasset that is the subject of thetransaction, as indicated in the vault of the cryptoasset, to determinewhich individuals' authorizations (endorsements) may be used to satisfya quorum to approve the withdrawal. The online server 2 then sends (step306) endorsement requests to the mobile devices 8A, 8B of thoseindividuals (the mobile devices have been previously registered with theCCS 1). In response to these requests, one or more endorsement messagesmay be received from users' mobile devices 8A, 8B, where the endorsementmessages were signed locally by the users' respective private keysstored securely in their respective mobile devices and subjected to oneor more biometric authentication techniques, as described further below.Accordingly, the online server 2 determines (step 304) whether, within atimeout period, a quorum of authorizations have been received and thecorresponding authorizing parties have been authenticated, as specifiedin the policy for this cryptoasset. If so, the online server 2 passes(step 305) the transaction request 31 to the risk analysis stage 4.Otherwise, the online server sends (step 310) a transaction denialnotification to at least the user who requested the transaction (andpossibly to all other users identified in the policy for thiscryptoasset).

The risk analysis stage 4 performs a risk analysis (step 306), which asnoted above may be fully or partially automated, or in some embodimentsmay be performed entirely by one or more human beings (based on computeroutput data). If the transaction passes risk analysis (step 306), thencontrol flow is passed to the HSM 5, which verifies (step 308) that thequorum requirement has been satisfied, by performing the samedetermination as step 304 or a similar determination, as does the riskanalysis stage 4 (step 306) (described further below). If satisfactionof the quorum is verified by the HSM 5, the HSM signs the withdrawaltransaction with the private key of the blockchain address and submitsthe transaction onto the blockchain 11 to execute the withdrawal (step309). Otherwise, the HSM 5 signals a failure to the online server 2,which in response sends (step 310) a transaction denial notification toat least the user who requested the transaction (and possibly to allother users identified in the policy for this cryptoasset).

User Authentication

As mentioned above, when a user endorses a transaction request, they aresubjected to one or more forms of authentication by their mobile deviceand/or the CCS 1, to establish that they are the expected person takingthe action. These authentication forms may include one or more biometricauthentication techniques, such as fingerprint verification, voiceprintverification, speech recognition, facial recognition and/or gesturerecognition. The user's mobile device (e.g., smartphone) may perform oneor more of these authentication techniques.

Additionally, or alternatively, the user may be required to upload tothe CCS 1 a video, captured by their mobile device, from which theiridentify can be proven by, for example: identifying the user's face inthe video against images of known faces (e.g., previous videos of theuser); identifying the user's voice in the video against their trainedvoice profile; requiring the user to say certain words or take certainactions in the video based on the transaction (see further discussionbelow); requiring the user to make a previously specified gesture, or adistress gesture if they are in distress; requiring the user to identifyon video the expected room they are in; and/or other performing anyother actions that are considered to increase the level of confidencethat the user is who he or she purports to be.

When determined to be necessary, a user may be asked to completechallenges to authenticate that he or she is in fact the person who isauthorized to act on the transaction. These challenges may be generateddeterministically based on the context of the transaction. For example,based on critical information in a transaction such as the ID, amount,destination, etc., the CCS 1 may generate a random number that can beused to select a few (e.g., three to five) words from a set of knownwords. The CCS 1 may present those words to the user and have the userspeak them in a video captured by the user's mobile device, which theuser's mobile device then transmits to the CCS 1. When reviewing thetransaction, the reviewing mechanism or a human reviewer canindependently generate the expected words based on transaction data andverify that the user spoke those words. The video can also be subject tofacial and/or voice recognition. By performing this type ofdeterministic challenge generation, an attacker can be prevented fromfaking a transaction by capturing and reusing previously transmittedauthentication videos from the user.

HSM Logic

The main role of the HSM 5 is to verify the validity of operations. TheHSM 5 carries out the will of the signers and authenticates that thesigners are the authorized parties of an operation through the HSM'sprivileged access to keys. Keys needed for signing transactions arestored securely in the HSM 5 and never leave it. In some embodiments,the HSM 5 enforces these policies through a Secure Execution Environment(SEE) that runs code that cannot be changed except through physicalaccess to the HSM 5 and requires a set of smartcards held securely bymultiple employees of the Cryptoasset Custodian.

In certain embodiments, to facilitate the above-mentioned functionalitythe HSM 5 stores, in its internal storage 7, multiple instances of adata structure called “Organization,” i.e., one instance for eachcustomer of the Cryptoasset Custodian. The Organization data structuremay contain the following fields: an identifier (ID) of theorganization, a name of the organization, a public key of theorganization, a list of users who belong to the organization, a policymap, a list of vaults that belong to the organization and theirrespective policy maps, and a generation number that is incremented eachtime the organization structure is updated. A “policy map” is a set ofpolicies, including one policy for each possible action that may becarried out (e.g., add user, change vault policy, etc.). An Organizationis signed by the HSM, using the Organization's private key (which isstored in the HSM 5 and cannot be read by any external entity), toindicate that it was produced through a valid set of changes authorizedby the users and risk reviewers. The HSM keeps track of the most recentversion to prevent rollback attacks.

To onboard a new customer, the HSM 5 creates a new Organizationinstance. To help ensure adequate security, the HSM 5 may create theOrganization with the requested set of users already in it. In someembodiments, the HSM 5 must generate new unique keys for every newOrganization created this way. This prevents an attacker from asking theHSM 5 to generate a “new” organization that has the same ID as anexisting one and tricking users into trusting it instead.

FIG. 4 illustrates an example of a process that may be performed by theHSM 5, in at least some embodiments, in response to a request to carryout an operation. The request may be received by the HSM 5 from therelay server 3. Initially, the HSM 5 receives (step 401) from the relayserver 3 an operation description, which specifies an Organization. Theoperation description is a set of data and metadata describing arequested operation, such as a requested deposit, withdrawal or transferof cryptocurrency. The HSM 5 then verifies (step 402) the integrity ofthe specified Organization.

The HSM 5 then looks up the policy in the Organization's or the vault'spolicy map (step 403). It then looks at the policy for internal riskreviewers to determine which and how many internal risk endorsements(i.e., endorsements by personnel of the Cryptoasset Custodian) must befulfilled (step 404). Next, the HSM 5 determines (step 405) whether anyof the received endorsements (from users) indicates to “REJECT” therequested operation. If so, the HSM 5 rejects (step 411) the requestedoperation, by returning a “REJECT” message to the relay server, whichthen returns a corresponding “REJECT” message to the online server, tocause notification to the requester. In this case, the HSM 5 does notbother checking the signatures and just rejects the operation.

The HSM 5 then determines (step 406) whether all of the receivedendorsements for the transaction are valid. This includes verifying thevalidity of the endorsements provided by checking that: i) the user isin the Organization, ii) the signature is correct for the specifiedoperation, and iii) each of the signatures has an “APPROVE” decision. Ifnot all of the received endorsements for the transaction are valid, theprocess proceeds to step 411 as described above.

If all received endorsements for the transaction are valid, the HSM 5then determines (step 407) whether the endorsements satisfy the relevantpolicy for the subject cryptoasset (i.e., satisfy the specified quorum).If the valid endorsements do not satisfy the policy, the processproceeds to step 411 as described above. If the endorsements satisfy thepolicy, then the HSM 5 determines (step 408) whether the requestedoperation passed the risk analysis stage. If not, the process proceedsto step 411 as described above. If the requested operation passed therisk analysis stage, the HSM 5 determines (step 409) whether therequested operation is valid. This step can include verifying that theoperation is internally consistent and that the operation can be appliedto the Organization, vault or asset that it targets. If the requestedoperation is not valid, the process proceeds to step 411 as describedabove. Otherwise, the HSM 5 executes (step 410) the requested operation(or triggers an action to cause it to be executed). An operation tochange the Organization, vault or policy results in a new signedOrganization data structure with a higher generation value and thechange applied to it. An operation to withdraw assets results in the HSM5 signing a blockchain transaction with the private key corresponding tothe subject asset. An operation to deposit assets results in the HSM 5generating a deposit address.

Offline Device Endorsements

As a method for reducing the risk for users interacting with the CCSapplication on their personal devices, the CCS 1 may requireauthorization from an offline device. This device, such as a consumerphone with secure enclave or similarly capable computing device such asan iPod Touch, will be completely disconnected from the Internet in itsnormal state, and used in an offline manner to sign transactionsrequired for authorization.

The process may be carried out as follows. The user has a phone orsimilar device that is a member of his or her vault policy's quorum andis not connected to any wireless or cellular networks. The device runssoftware similar to the CCS application software for enabling a user toendorse requested transactions, or the same software operating in adifferent mode. The user initiates a transaction against his or hervault through a different device in the quorum. An online device, suchas another phone or web browser, has access to the transaction. It maybe another phone/secure device in the quorum or it may exist solely forthe purpose of displaying transactions. The device has the ability totransmit data that is required to be signed by the offline device, tothe offline device. This can be done through a channel that cannot beaccessed over the Internet, such as displaying a QR code, playing asound or sequence of sounds that encodes data, or transmitting overBluetooth. The offline device displays the data that was transmitted forit to sign, for the user's approval or rejection. The offline devicesigns its endorsement of the operation based on the user's desiredaction. The offline device communicates its signed payload back to theonline device in a similar manner to how it was received (e.g.,displaying a QR code, playing a sound or sequence of sounds that encodesdata, or transmitting over Bluetooth). The online device communicatesthe signed decision payload back to the online server of the CCS 1.

FIG. 5 is a flow diagram that further illustrates this process,according to certain embodiments. An online user device receives (step501) an operation description from the CCS via the Internet. The onlineuser device then transmits (step 502) the operation description (or aportion thereof) to the offline user device file an offline channel. Asnoted above, the offline channel is a channel that is not accessible viathe Internet, such as a local visual display by the online user device,a sound or sequence of sounds generated by the online user device, or ashort range wireless transmission from the online user device (e.g., viaBluetooth). The offline user device receives the operation description(step 503) from the online user device via the offline channel, andbased on the information thereby received, displays the operationdescription (or portion thereof) and prompts the user for endorsement ofthe operation (step 504). If a valid endorsement is received by theoffline device (step 505) as user input within a timeout period, theoffline device transmits an “ACCEPT” message (step 506) to the onlineuser device via the same offline channel by which it received theoperation description, or via a different offline channel. The onlineuser device then receives the results of the endorsement from theoffline device (step 507) and transmits the result payload to the CCSvia the Internet (step 508). If a valid endorsement is not received bythe offline user device from the user within the timeout period (step505), the offline user device transmits a “REJECT” message to the onlineuser device via the offline channel, which in turn transmits the“REJECT” payload to the CCS via the Internet (step 508).

The offline device may be delivered to the user with its secure keypre-enrolled in the Organization, or it may be allowed to be online forthe initial enrollment process, or it may send its enrollment through asimilar procedure to the authorization process.

The CCS software on the offline device may need to be updatedperiodically. To allow such updates, the offline device may be scheduledto connect to the Internet via Wi-Fi and have its software updated at apredefined cadence, or it may detect that its software needs to beupdated as a result of receiving a transaction to sign from the onlineuser device, that indicates that the version of the software on theoffline device is no longer compatible. Whenever the device is online,it can record as well as attempt to transmit to the CCS 1 the fact thatit can access the Internet so that that information may be used toassess risk by the platform at a later time.

In addition to being kept offline, the offline user device and one ormore online devices may be restricted to act on a transaction only whenin range of a predefined beacon. A wireless (e.g., Bluetooth) beacondevice can be made available to the user, and the CCS application mayrefuse to authorize transactions unless it detects that the beacon isavailable.

Auditability and Proof of Ownership

Every transaction submitted to the CCS 1 is recorded in an internalledger that is tamper-resistant and that allows auditors to havecryptographic proof of every historical event on every user's account.The ownership of a blockchain asset is controlled by the possession ofthe private key corresponding to the public wallet address. The CCS canprove ownership of these assets to auditors by making use of the privatekey corresponding to a user's vault to sign a string of randomly chosentext chosen by the auditors. Consider the following example:

An auditor wishes to see proof that the CCS has access to funds inwallet identified by the address, “1BvBMSEYstn5Au4m4GFg7yJaNVN2.” Theauditor therefore randomly generates a long string, e.g.,“xGG8vQFnd8QDwHz6Uj1GX,” and submits the following challenge:

{ Address: 1BvBMSEYstn5Au4m4GFg7yJaNVN2 , Token: “ AUDIT-CHALLENGE-xGG8vQFnd8QDwHz6Uj1GX”, }

The CCS 1 receives the challenge and forwards it to the HSM 5 as apredefined templated serialized package. The HSM 5 is programmed toaccept and sign such audit requests (which are not arbitrary payloadsand therefore are not at risk of being later interpreted as a signedblockchain transaction) with the private key associated with thespecified address. The CCS 1 then returns the valid signature for thechallenge that can be independently verified by the auditor. Thisverification proves that the CCS 1 has control over a private keyassociated with an entry on the blockchain, achieving proof of controlof the asset.

Thresholding Service

In certain embodiments, the CCS 1 includes a Thresholding Service thatenables other parts of the system (Risk Analysis stage 4 and HSM 5) tosecurely determine that user operations and transactions have followedthe customer specific business logic and have been approved by ahuman/automated risk review system. The Thresholding Service can verifymulti-signature (multi-user) quorums to achieve this.

The Thresholding Service validates operations initiated and approved byusers to ensure that they've met a threshold quorum before beingexecuted. Such operations may include transactions, adding or removingother users, etc. Different users can have different access controlroles (e.g., view-only, initiate-transaction-only, authorizable,necessary). The CCS 1 is able to notify every reportable status of thequorum acceptance lifecycle, but is not able to sign-off on operationsthat have not been authorized by customers. All actions are logged in anappend-only ledger for auditability over all account interactions.

One function of the Thresholding Service is to verify that a quorum ofauthorized users have signed-off on a requested operation. Qualifyingoperations that may require a quorum may include, for example, proposinga transaction (e.g., “withdraw 100 Bitcoin”), adding a user to anaccount, changing a user's permissions, removing a user from an account,and changing the thresholding logic. A quorum may be defined as anabsolute majority of users by default (e.g., 3 out of 5), or it may beset to a custom quorum upon onboarding of the customer. Moreover, anauthorized user can configure a quorum to require certain specific usersto endorse a transaction to constitute a quorum. The CCS 1 may alsoallow thresholding across multiple required groups. For example, in acompany a majority of the finance team may be required to sign off, aswell as the front office.

In certain embodiments, the Thresholding Service implements afine-grained access control model in its quorum verification, in whichdifferent users can have different access levels, which may include thefollowing levels, for example:

View-only

-   -   This is the default access level    -   Users in this level can view all asset positions    -   Users in this level can flag any transaction    -   Users in this level can freeze all assets

View-authorize

-   -   Users in this level can act as an authorizing vote for an action        toward a quorum    -   Users in this level can view all asset positions    -   Users in this level can flag any transaction    -   Users in this level can freeze all assets

View-authorize-necessary

-   -   Users in this level are a required vote for an action    -   Users in this level can view all asset positions    -   Users in this level can flag any transaction    -   Users in this level can freeze all assets

In certain embodiments, the access level for a user can only be changedwith an appropriately verified quorum that is verified by theThresholding Service.

As noted above, user approvals for an action can be expressed by acryptographic digital signature, to benefit from non-repudiationguarantees. The Cryptoasset Custodian can be certain that the associateduser who holds the private key was indeed the user who approved theaction, since digital signatures cannot be forged. In certainembodiments, a user's signature is generated from an iOS secure enclavein the user's mobile device, and forwarded to the CCS 1 by the iOSapplication programming interface (API) component in the user device 8.Signatures can be performed over the cryptographic hash of thetransaction contents to ensure that the transaction cannot be tamperedwith. All users may be required to sign the same hash for the sametransaction identifier (ID) in order for the signatures to count towardthe quorum. The Thresholding Service can provide templates for theclients to sign, and can verify all completed signatures completed bythe iOS client. In at least some embodiments, the Thresholding Serviceverifies signatures with the public components of the users' signingkeys, but does not hold the private components of those user signingkeys.

Once a threshold has been satisfied, the Thresholding Service willpublish the corresponding signature data to the Risk Analysis stage tobe further analyzed before sign-off by the Risk Analysis stage, and willserialize the signature data into a payload to be consumed by the HSMsigning service. Each additional signature provided to the ThresholdingService and verification can be recorded in the append-only log service.This will provide additional auditing and status updates in addition tothe metadata captured in the Thresholding Service's storage, which willbe essential for providing consumable updates to user clients.

Maintaining Quorum Liveness

It is assumed that authorized members of a quorum are available tocryptographically sign transactions. Therefore, the quorum should bekept “live”—that is, at any given time, the CCS 1 has reasonableconfidence that all potential members of the quorum maintain possessionof their secure device keys and can actively participate in atransaction. In certain embodiments, the CCS 1 can do the following toachieve this level of confidence:

-   -   1. Have access to the set of user public keys required to        fulfill a policy's quorums.    -   2. Set a liveness threshold for a policy, i.e., the amount of        time after which one considers a key to be at risk of        unavailability. This can be fixed or related to normal        transaction cadence.    -   3. Require users to periodically sign a proof transaction with        their private keys. This can be explicit as a liveness check or        hidden/implicit by requiring their key for routine operations        such as login.    -   4. Record the latest live time of any one or more users' keys.    -   5. Continuously monitor whether any user's live time has        exceeded the liveness threshold.    -   6. Use the above information to prompt the user to prove they        still have access to their signing key and/or inform other users        that the quorum may be at risk.

Risk Analysis Stage

The Risk Analysis stage 4 can implement an API, called the Risk API, andcan further include human review of all transactions and administrativeuser operations. In some embodiments the Risk API drives the humanreview system. The Risk API can provide integration with an internalrisk dashboard, for human employees of the Cryptoasset Custodian tomanually review each transaction.

In certain embodiments, all transactions are manually approved bydesignated employee(s); all administrative user operations (adding,removing, permission changes) are manually approved by designatedCryptoasset Custodian employee(s); reviewable entities must have passedan automated verification process before requiring risk analysis;reviewable entities must provide robust context about the userapprovals, for both human and further automated inspection; and riskapprovals and denials are logged in an append-only ledger forauditability.

The Risk API reverifies the appropriate threshold as determined by theThresholding Service. The Risk API may also handle additional businesslogic, such as in embodiments where the Thresholding Service issimplified: for example, the Risk API could check for necessary signersif the Thresholding Service only checks for quorums. Other functionsdescribed herein can also be moved between modules.

The Risk API can receive contextual data about each user involved in atransaction, to present to a human and/or classification system. Thisinformation may include, for example, user(s) who approved thetransaction, time of approval(s), location of approval(s), anddevice/key ID(s) that approved the transaction. This data can be fedinto an internal Risk Analysis dashboard, and possibly other automatedreview systems.

In some embodiments, the Risk API requires human approval from one ormore employees of the Cryptoasset Custodian if a transaction passes themanual and automated risk review. To approve, an employee may berequired to sign with a cryptographic key if he or she approves thetransaction/operation and present the signature to the Risk API forvalidation. Moreover, there are preferably multiple keys, one per riskreviewer, such that it is logged who performed the review. Preferably itis made easy to rotate a risk-approval key in case of compromise.

FIG. 6 shows a high-level example of a hardware architecture of aprocessing system that can be used to implement some or all of the CCS,or (separately) any user device, or both. The CCS can include one ormore instances of an architecture such as shown in FIG. 6, wheremultiple such instances can be coupled to each other via one or moreprivate networks.

The illustrated processing system 600 includes one or more processors,including a CPU 610, one or more memories 611 (at least a portion ofwhich may be used as working memory, e.g., random access memory (RAM)),one or more data communication device(s) 612, one or more input/output(I/O) devices 613, and one or more mass storage devices 614, all coupledto each other through an interconnect 615. The interconnect 615 may beor include one or more conductive traces, buses, point-to-pointconnections, controllers, adapters and/or other conventional connectiondevices. Each processor 610 controls part of the operation of theprocessing device 600 and can be or include, for example, one or moregeneral-purpose programmable microprocessors, digital signal processors(DSPs), mobile application processors, microcontrollers, applicationspecific integrated circuits (ASICs), programmable gate arrays (PGAs),or the like, or a combination of such devices.

Each memory 611 can be or include one or more physical storage devices,which may be in the form of RAM, read-only memory (ROM) (which may beerasable and programmable), flash memory, miniature hard disk drive, orother suitable type of storage device, or a combination of such devices.Each mass storage device 614 can be or include one or more hard drives,digital versatile disks (DVDs), flash memories, or the like. Each memory611 and/or mass storage 614 can store (individually or collectively)data and instructions that configure the processor(s) 610 to executeoperations to implement the techniques described above. Eachcommunication device 612 may be or include, for example, an Ethernetadapter, cable modem, Wi-Fi adapter, cellular transceiver, basebandprocessor, Bluetooth or Bluetooth Low Energy (BLE) transceiver, or thelike, or a combination thereof. Depending on the specific nature andpurpose of the processing system 600, each I/O device 613 can be orinclude a device such as a display (which may include a transparent ARdisplay surface), audio speaker, keyboard, mouse or other pointingdevice, microphone, camera, etc. Note, however, that such I/O devicesmay be unnecessary if the processing device 600 is embodied solely as aserver computer.

In the case of a user device, a communication device 612 can be orinclude, for example, a cellular telecommunications transceiver (e.g.,3G, LTE/4G, 5G), Wi-Fi transceiver, baseband processor, Bluetooth or BLEtransceiver, or the like, or a combination thereof. In the case of aserver, a communication device 612 can be or include, for example, anyof the aforementioned types of communication devices, a wired Ethernetadapter, cable modem, DSL modem, or the like, or a combination of suchdevices.

Unless contrary to physical possibility, it is envisioned that (i) themethods/steps described herein may be performed in any sequence and/orin any combination, and that (ii) the components of respectiveembodiments may be combined in any manner.

The machine-implemented operations described above can be implemented byprogrammable circuitry programmed/configured by software and/orfirmware, or entirely by special-purpose (“hardwired”) circuitry, or bya combination of such forms. Such special-purpose circuitry (if any) canbe in the form of, for example, one or more application-specificintegrated circuits (ASICs), programmable logic devices (PLDs),field-programmable gate arrays (FPGAs), system-on-a-chip systems (SOCs),etc.

Software or firmware to implement the techniques introduced here may bestored on a machine-readable storage medium and may be executed by oneor more general-purpose or special-purpose programmable microprocessors.A “machine-readable medium”, as the term is used herein, includes anymechanism that can store information in a form accessible by a machine(a machine may be, for example, a computer, network device, cellularphone, personal digital assistant (PDA), manufacturing tool, any devicewith one or more processors, etc.). For example, a machine-accessiblemedium includes recordable/non-recordable media (e.g., RAM or ROM;magnetic disk storage media; optical storage media; flash memorydevices; etc.), etc.

The term “logic”, as used herein, means: i) special-purpose hardwiredcircuitry, such as one or more application-specific integrated circuits(ASICs), programmable logic devices (PLDs), field programmable gatearrays (FPGAs), or other similar device(s); ii) programmable circuitryprogrammed with software and/or firmware, such as one or more programmedgeneral-purpose microprocessors, digital signal processors (DSPs) and/ormicrocontrollers, system-on-a-chip systems (SOCs), or other similardevice(s); or iii) a combination of the forms mentioned in i) and ii).

Any or all of the features and functions described above can be combinedwith each other, except to the extent it may be otherwise stated aboveor to the extent that any such embodiments may be incompatible by virtueof their function or structure, as will be apparent to persons ofordinary skill in the art. Unless contrary to physical possibility, itis envisioned that (i) the methods/steps described herein may beperformed in any sequence and/or in any combination, and that (ii) thecomponents of respective embodiments may be combined in any manner.

Although the subject matter has been described in language specific tostructural features and/or acts, it is to be understood that the subjectmatter defined in the appended claims is not necessarily limited to thespecific features or acts described above. Rather, the specific featuresand acts described above are disclosed as examples of implementing theclaims and other equivalent features and acts are intended to be withinthe scope of the claims.

What is claimed is:
 1. A method of authorizing an action, the methodcomprising: receiving, at a server system, an action request for arequested action; using a hardware security module in the server systemto determine whether a policy-based quorum of a plurality of users hasapproved the requested action, by using a public key of a public-privatekey pair for each of the plurality of users; and only after determiningthat the policy-based quorum of the plurality of users has approved ofthe requested action, approving the action by using the hardwaresecurity module to sign an approval message for the action with acryptographic key that is stored only in the hardware security module,wherein the hardware security module does not permit the cryptographickey to be read by any entity outside the hardware security module.
 2. Amethod as recited in claim 1, wherein, for each of the plurality ofusers, a private key of the public-private key pair for said user isstored within a secure storage of a mobile device associated with saiduser.
 3. A method as recited in claim 1, wherein the requested actioncomprises a requested transaction involving a digital asset.
 4. A methodas recited in claim 1, further comprising sending the transaction onto ablockchain network in response to approving the transaction.
 5. A methodas recited in claim 1, wherein the requested action comprises arequested transaction involving an asset, wherein the cryptographic keyis a private key of a public-private key pair associated with the asset,the method further comprising using the hardware security module togenerate the cryptographic key.
 6. A method as recited in claim 1,further comprising: causing an endorsement request message to betransmitted to each of a plurality of user devices, each of theplurality of user devices associated with a different one of theplurality of users, each endorsement request message being configured tocause a receiving user device to prompt a corresponding user to endorsethe requested transaction.
 7. A method as recited in claim 6, furthercomprising: for at least two of the user devices, verifying, at theserver system, that the user device has authenticated a correspondinguser by use of a biometric authentication technique, in connection withan endorsement of the requested transaction.
 8. A method of authorizinga transaction involving a cryptoasset, the method comprising: receiving,at a server system, a transaction request for a requested transactioninvolving the cryptoasset; receiving, at the server system, at least oneendorsement message from at least one user device, each said at leastone endorsement message being associated with a different one of aplurality of users; determining, by a hardware security module in theserver system, whether the at least one endorsement message satisfies aquorum for approving the requested transaction, the quorum being definedin a stored policy associated with the cryptoasset; and only if the atleast one endorsement message satisfies the quorum, then authorizing therequested transaction by using the hardware security module to sign anapproval of the requested transaction with a private key associated withthe cryptoasset.
 9. A method as recited in claim 8, further comprising:for at least one user device of said at least one user device,verifying, at the server system, that the user device has authenticateda corresponding user by a first biometric authentication technique, inconnection with an endorsement of the requested transaction.
 10. Amethod as recited in claim 9, further comprising using a secondbiometric authentication technique at the server system to authenticateat least one of the users in connection with an endorsement of therequested action.
 11. A method as recited in claim 8, further comprisingusing an authentication technique at the server system to authenticate auser in connection with an endorsement of the requested transaction, theauthentication technique including: causing a user device of the user tooutput a prompt the user to record and upload to the server system avideo in which the user performs a specified action or speaks specifiedcontent; receiving at the server system a video uploaded responsive tothe prompt; and analyzing the video at the server system to authenticatethe user by performing at least one of: verifying a biometriccharacteristic of the user from the video, or verifying that the userperformed the specified action or spoke the specified content in thevideo.
 12. A method as recited in claim 8, further comprising: causing auser device of at least one of the users to output a deterministicauthentication challenge to the corresponding user, wherein a content ofthe deterministic authentication challenge is based on a context of therequested transaction.
 13. A method as recited in claim 8, furthercomprising: in response to the transaction request, invoking a riskanalysis of the requested transaction; wherein said authorizing thetransaction is done only if a result of the risk analysis indicates thata risk level associated with the requested transaction satisfies a riskcriterion and the at least one endorsement message satisfies the quorum.14. A method as recited in claim 8, further comprising: using thehardware security module to generate the private key associated with thecryptoasset.
 15. A method as recited in claim 8, further comprising:using the hardware security module to generate the private keyassociated with the cryptoasset as part of a public-private key pairassociated with the cryptoasset.
 16. A method as recited in claim 15,further comprising: storing the private key associated with thecryptoasset within the hardware security module, wherein the private keyassociated with the cryptoasset cannot be read by or transmitted to anyentity that is external to the hardware security module.
 17. A method asrecited in claim 8, further comprising: storing in the hardware securitymodule a public key of a public-private key pair for each said at leastone user device.
 18. A method as recited in claim 17, wherein eachendorsement message has been signed by a corresponding user device withthe private key of the public-private key pair associated with saidcorresponding user device.
 19. A method as recited in claim 17, furthercomprising: providing a data package to the hardware security moduleprior to said authorizing the requested transaction, the data packageincluding data indicative of the quorum and a public key associated witheach said at least one user device.
 20. A method as recited in claim 8,wherein the hardware security module has no direct connection to anypublic computer network.
 21. A method as recited in claim 8, storing, ina hardware security module, a private key associated with thecryptoasset, the private key being part of a public-private key pairassociated with the cryptoasset.
 22. A method as recited in claim 8,causing, by the server computer system, an endorsement request messageto be transmitted to each said at least one user device, eachendorsement request message being configured to cause the receiving userdevice to prompt a corresponding user to endorse the requestedtransaction.
 23. A method as recited in claim 8, storing the policyassociated with the cryptoasset, the policy defining a quorum of aplurality of users required for authorization of the transaction.
 24. Amethod as recited in claim 8, wherein the determining whether the atleast one endorsement message satisfies a quorum defined in a policyassociated with the cryptoasset is done by using a public key associatedwith the user device that sent each endorsement message to validate thecorresponding endorsement message.
 25. A method as recited in claim 8,wherein the at least one endorsement message has been generated bysigning on the user device using a private key stored in a securestorage of the user device.
 26. A method as recited in claim 8, furthercomprising: sending to the hardware security module a data package thatincludes data specifying the policy, including the quorum, and a publickey associated with each said at least one user device.
 27. A method ofauthorizing a transaction, the method comprising: receiving, at a servercomputer system from a user device via a public computer network, atransaction request for a requested transaction relating to acryptoasset; in response to the transaction request, invoking a riskanalysis of the requested transaction; accessing, by the server computersystem, a stored policy associated with the cryptoasset, the policyspecifying a quorum of a plurality of users required for authorizationof the transaction; causing, by the server computer system, anendorsement request message to be transmitted to each of a plurality ofmobile devices, each of the mobile devices being associated with adifferent one of the plurality of users, each endorsement requestmessage being configured to cause the receiving mobile device to prompta corresponding user to endorse the requested transaction; receiving, atthe server computer system, an endorsement message from at least one ofthe mobile devices, each endorsement message indicative of anendorsement of the requested transaction by a user using a correspondingone of the mobile devices, each endorsement message having been signedby the corresponding mobile device with a private key stored in a securestorage in the corresponding mobile device; storing, in a hardwaresecurity module that has no direct connection to any public computernetwork, a private key associated with the cryptoasset, the private keybeing part of a public-private key pair associated with the cryptoasset;determining, by the hardware security module, whether a validendorsement has been received from each of two or more of the mobiledevices in satisfaction of the quorum specified in the policy, by usinga public key associated with the mobile device that sent eachendorsement message to validate the corresponding endorsement message;and only if the risk analysis has determined that a level of riskassociated with the requested transaction is below a threshold and avalid endorsement of the requested transaction has been received fromeach of two or more of the mobile devices in satisfaction of the quorum,then authorizing the transaction by using the hardware security moduleto sign an approval of the requested transaction with the private keyassociated with the cryptoasset.
 28. A digital asset custodial systemcomprising: an online server subsystem configured to receive a requestedtransaction relating to a digital asset from a user via a publiccomputer network and to cause an endorsement request to be sent to atleast one mobile device according to a stored policy in response toreceipt of the requested transaction, each said at least one mobiledevice being associated with at least one of a plurality of usersspecified in the policy as possible members of a quorum for approvingthe transaction, the online server subsystem further configured toreceive an endorsement message from the corresponding mobile device ofone or more of the plurality of users; and a hardware security moduleconfigured to receive an indication of the endorsement message from amobile device of one or more of the users, to determine whether validendorsements have been received from each of two or more of the users insatisfaction of the quorum specified in the policy, based on a publickey associated with each of the plurality of users for which anendorsement message has been received, and to authorize the transactionby signing an approval of the requested transaction with a private keyassociated with the digital asset only if a valid endorsement of therequested transaction has been received from each of two or more of theusers in satisfaction of the quorum.
 29. A digital asset custodialsystem as recited in claim 28, further comprising a relay server toisolate the security module from the Internet.
 30. A digital assetcustodial system as recited in claim 28, further comprising a riskanalysis module to assign a risk score to the requested transaction. 31.A digital asset custodial system as recited in claim 28, the onlineserver subsystem further being configured to cause an endorsementrequest message to be transmitted to each of a plurality of mobiledevices, each endorsement request message being configured to cause thereceiving mobile device to prompt a corresponding user to endorse therequested transaction.
 32. A digital asset custodial system as recitedin claim 28, wherein the hardware security module is further configuredto: generate the private key associated with the digital asset as partof a public-private key pair associated with the digital asset; providea public key of the public-private key pair associated with the digitalasset to a computer system that is external to the hardware securitymodule; and maintain the private key of the public-private key pairassociated with the digital asset in a storage within the hardwaresecurity module and prevent the private key of the public-private keypair associated with the digital asset cannot from being read by anyentity that is external to the hardware security module.
 33. A digitalasset custodial system as recited in claim 28, and configured to verify,for at least one user device, that the user device has authenticated acorresponding user by a first biometric authentication technique, inconnection with an endorsement of the requested transaction.
 34. Adigital asset custodial system as recited in claim 33, furtherconfigured to use a second biometric authentication technique toauthenticate at least one of the users in connection with endorsement ofthe requested action.
 35. A digital asset custodial system as recited inclaim 28, and configured to authenticate a user in connection withendorsement of the requested transaction, by: causing a user device ofthe user to output a prompt to the user to record and upload to theserver system a video in which the user performs a specified action orspeaks specified content; receiving a video uploaded responsive to theprompt; and analyzing the video to authenticate the user by performingat least one of verifying a biometric characteristic of the user fromthe video, or verifying that the user performed the specified action orspoke the specified content in the video.
 36. A digital asset custodialsystem as recited in claim 28, and configured to cause a user device ofat least one of the users to output a deterministic authenticationchallenge to the corresponding user, wherein a content of thedeterministic authentication challenge is based on a context of therequested transaction.
 37. A hardware security module comprising: anon-volatile storage to store cryptographic data; a communicationinterface through which to communicate with a host computer system; andlogic circuitry coupled to the non-volatile storage and thecommunication interface and configured to cause the hardware securitymodule to perform operations including: receiving an indication of adeposit of a digital asset, from a calling process; in response to theindication, generating a public-private key pair associated with thedigital asset, providing a public key of the public-private key pair tothe calling process, and storing the private key of the public-privatekey pair in the non-volatile storage in a protected manner; receiving anindication of a requested operation related to the digital asset, anindication of a quorum of users whose endorsements of the requestedoperation are required to authorize the requested transaction, and apublic key associated with each of one or more of the plurality of userswho ostensibly have endorsed the requested transaction; determiningwhether a valid endorsement has been received from two or more users ofthe plurality of users in satisfaction of the quorum, based on theindication of the quorum and the public key associated with each of oneor more users who ostensibly endorsed the requested transaction; andafter a determination that a valid endorsement has been received fromtwo or more users in satisfaction of the quorum, authorizing therequested transaction by signing an approval of the requestedtransaction with the private key of the public-private key pairassociated with the digital asset.
 38. A hardware security module asrecited in claim 37, wherein the private key of the public-private keypair associated with the digital asset is prevented from being read byany entity external to the hardware security module.
 39. A hardwaresecurity module as recited in claim 37, the operations further includingcausing the transaction to be transmitted onto a blockchain network onlyafter said signing the approval of the transaction.
 40. A methodcomprising: receiving, at first user device associated with a user, afirst message including a transaction description relating to arequested transaction, from a server system via a public computernetwork; in response to the first message, transmitting a second messageincluding an indication of the transaction from the first user device toa second user device associated with the user, via a firstpoint-to-point channel that is isolated from the public computernetwork, wherein the second user device is isolated from the publiccomputer network, the second message to cause the second user device tooutput a description of the transaction and to prompt the user toendorse the transaction; receiving, at the first user device from thesecond user device, a third message indicative that the user has usedthe second user device to endorse the transaction, the third messagebeing received via the first point-to-point channel or via a secondpoint-to-point channel that is isolated from the public computernetwork; and in response to the third message, sending a fourth messageindicative that the user has endorsed the transaction, from the firstuser device to the server system via the public computer network.